PrizmDoc v12.0 -
Overview
| Working with PrizmDoc > Administering PrizmDoc > System Configuration > Overview |
PrizmDoc and its components can be configured in numerous ways to address different use cases. This article will give a brief overview of some of the more common configuration cases as well as serve as a roadmap to find more information about how to configure the system to best address your needs.
The Viewing Client is a highly customizable component that we’ve embedded into our web-tier applications that can be used out of the box or customized and integrated into other applications. For an overview of the Viewing Client’s architecture, please refer to the Viewing Client Overview.
The Viewing Client has several options that change they way the viewer plugin is initialized. These plugin options are formatted as a JavaScript object that is passed in when the viewer plugin is created by the client side application. These options are specific to a single instance of the viewing application, and they can be configured independently of other instances of the viewer. For a full description of the options available, refer to our Namespace: fn API topic.
Additionally, refer to our Configuration Options topic for some examples on how to configure the Viewing Client to suit your needs. For example, if you want to configure protection for the content in the viewer, refer to the DRM and Content Encryption articles.
PrizmDoc Application Services, or PAS, is a service that provides a layer of application-level logic for the PrizmDoc Viewing Client. For an overview of how PAS integrates into most systems please refer to the PAS Overview.
PrizmDoc Application Services configuration should begin with taking a look at the PAS Configuration article, which will address most of the common configuration questions.
If you're new to PAS, but are an existing PrizmDoc customer, take a look at our migration topic. There you can find more information about how to override specific PAS routes if, for example, your application was using custom storage for your markup files. If your application used much of the logic from our earlier web-tier samples, refer to the Legacy Mode section in our PAS Configuration topic to enable support for markup files created with those samples.
We also have examples about how to configure PAS in your server's entry point; however, if the proxying examples are not feasible for your deployment, you can decide if you need to use CORS with PAS.
If your application will require more bandwidth than a single server can provide, review our comments regarding running PAS on multiple servers.
PrizmDoc Server is a collection of different services that can accomplish, and be used by, various workflows. In past iterations, there were multiple configuration files that an administrator would work with to configure their system. PrizmDoc Server now relies on a single Central Configuration for both Windows and Linux installations.
While legacy configuration files are still compatible, existing PrizmDoc customers will want to upgrade their legacy configuration to the new central configuration for greater simplicity. Please refer to the table in that topic to identify values that may have been set in your deployment and their corresponding values in Central Config.
Look to our Security Guidance if you want more information on how to take steps to secure the Viewing Session API against possibly malicious requests. Additionally, to prevent the potential to expose any network infrastructure information, see our topic on Changing Encryption Keys to non-default values.
By default, a single server with an instance of the PrizmDoc Server RESTful API needs only one port that is open to the rest of your network. The number of ports required increases to two with a multi-server configuration. However, PrizmDoc server consists of multiple micro-services that require a range of open, local ports to function. Refer to Configuring Ports for the PrizmDoc Server for more information and how to configure them.
PrizmDoc Server works most efficiently when it can rely on its cached content to service viewing, burning, and conversion requests. If the Server has already cached a document, the time between the initial request and the first page loads in the viewer is greatly reduced; however, if your usage means that the majority of viewed documents will be unique or you're not able to cache them, there may be very little to no benefit to maintaining a Server cache. Please see our Caching Strategies for a more detailed look at how and why PrizmDoc Server generates a cache and how that process can be optimized for your application. Additionally, see our Caching Parameters topic for greater detail on how to configure the duration of PrizmDoc Server’s cached content, where it is stored, and whether or not it is used at all. Please note that PrizmDoc Server's caching mechanism is not intended for long-term storage of converted content.
If the majority of content intended for viewing and conversion is Microsoft Office content (Word, Excel, Powerpoint), you may want to adjust some of the parameters related to Office conversion. Our Office Conversion Settings topic goes into some detail about which settings can be adjusted as well as the pros and cons of adjusting those parameters. Additionally, PrizmDoc Server uses some default values when converting Excel content for viewing. Depending on the layout of your content, those values may need to be adjusted or disabled entirely. See our Excel Pagination topic for more information.
If there are additional configuration topics that you have questions about, or you think are missing from the above, please contact support@accusoft.com or visit https://www.accusoft.com/support/.